All Categories :
Servers
Chapter 6
Windows NT 4 Configuration
CONTENTS
This chapter is here to give you some ideas about Windows NT configuration,
but it is not intended to replace the installation documentation
that comes with Windows NT. The information in this chapter covers
assorted topics that might be just enough for you to go on if
you have worked with other network operating systems before. If
you don't consider yourself an expert in networking, this chapter
alone isn't going to make you a system administrator, and I would
wholeheartedly advise you to pick up a copy of Windows NT Server
Survival Guide written by Rick Sant'Angelo and Nadeem Chagtai.
I consider their book to be perhaps the best buy on the market
when it comes to learning all the ins and outs of NT administration.
It's also the single best book to supplement this one on an NT
Webmaster's bookshelf, in my opinion.
Tip |
While I'm on the subject of useful sources for reference materials, I think that every Windows NT administrator should have a subscription to Windows NT Magazine. Each issue is packed with useful technical articles and product reviews to keep you informed about the BackOffice network.
|
When buying Windows NT, you have a choice between the Server version
and the Workstation version. Both are very capable, reliable,
32-bit, multithreading, preemptive-multitasking, GUI, network
operating systems. In version 4, the biggest difference between
the two is that the Server version now includes Internet Information
Server (IIS) for free. IIS includes a high-performance Web server,
an FTP server, and a Gopher server. (See Chapters 7 and
9.)
NT Workstation is more affordable than NT Server (street prices
around $260 versus $675, respectively). Although the Workstation
version is designed for better single-user performance, it can
also reliably handle a Web server. The Server version does have
several features that Workstation lacks, but most are probably
not critical to building an Intranet. The following list details
a few key differences:
- NT Server can support up to 1,000 simultaneous
LAN users, whereas NT Workstation can support up to 10.
- Although a special Workstation license
of SQL Server 6.5 is available for a single user, you must run
NT Server if you expect to support several database clients. (This
restriction is similar to the restriction that IIS must run on
NT Server.)
- NT Server supports the AppleTalk LAN protocol
for compatibility with Macintosh computers.
- The microkernel in NT Server is tweaked
for faster file server performance than NT Workstation.
When dealing with Intranets, the first difference in the preceding
list is not a problem. The number of Web clients that can simultaneously
connect to your server is not the same as the number of
LAN users. With either version of NT, the number of possible Intranet
client connections is limited by the performance of the network,
the hard disk, and other factors. The performance of the kernel
system software isn't really a major problem either, unless you
are planning to process hundreds of transactions per minute. Therefore,
I recommend NT Workstation for those who like to save a few hundred
dollars.
For the rest of this chapter, I'm going to assume that you have
already installed Windows NT 4. One of the first things you need
to do after installing NT is to get TCP/IP running as your primary
network protocol. As you recall from Chapter 1,
the Web requires TCP/IP. Now I must confess that I lied-sort of.
Thanks to the hard-working engineers at Microsoft, Winsock 2.0,
which has just been released in Windows NT 4, enables Windows
network applications to run transparently on other network protocols
besides TCP/IP. If you are considering not running TCP/IP on your
Intranet, keep in mind that this alternate protocol feature is
very new, and you should investigate it carefully before adopting
it. It may take some time to determine whether all Winsock 1.1
applications will run as is on Winsock 2.0 on top of alternate
protocols. Also, you would need to deploy Winsock 2.0 on all your
Intranet client machines. I haven't tested this feature, and I
can't see any great gain in not using TCP/IP. If you have other
pre-existing protocols that you must run in addition to TCP/IP,
such as NetBEUI and/or IPX/SPX, you can be confident that Windows
NT Server can handle practically everything you can dish up. (Windows
95 and Windows for Workgroups 3.11 can support up to three protocols
at once.)
Follow these steps to add TCP/IP to Windows NT Server 4 (similar
steps apply to NT Workstation):
- Click Start | Settings | Control Panel | Network | Protocols
| Add.
- Choose TCP/IP, as shown in Figure 6.1. Choose OK. Consider
removing other protocols, such as NetBEUI and IPX/SPX, if you
are sure that you do not need them on your LAN. If you can standardize
on just one protocol for all the computers on your LAN, TCP/IP
is a good one to choose because it is very capable.
Figure 6.1: Adding TCP/IP to the Network Protocols.
After you have TCP/IP installed, follow these steps to configure
the protocol:
- Click Start | Settings | Control Panel | Network | Protocols
| TCP/IP | Configure.
- Click the IP Address tab as shown in Figure 6.2.
Figure 6.2: Configuring the IP Address tab in the TCP/IP protocol.
- Unless another primary server exists on your network, you
don't have the option of obtaining your IP address from a DHCP
server (even if you decide to make this server a DHCP server for
the rest of your network). You must obtain a valid static IP address
for your NT server. Select the radio button that is titled Specify
an IP address, and then enter your address and the mask. (The
Dynamic Host Control Protocol, DHCP, is covered very lightly in
the following section, and subnet masks are briefly covered in
Chapter 28, "Connecting the Intranet
and the Internet." Detailed treatment of these subjects is
beyond the scope of this book.)
- Click the DNS tab, and give yourself a valid host name and
domain name. Depending on your network scheme, it is possible
to use a NetBIOS name to refer to the server rather than a DNS
host name. WINS and LMHOSTS are two ways to get that capability
on a TCP/IP network (see the next section).
- Click OK to close the Network dialog. You are prompted to
restart Windows NT for the changes to take effect.
Note |
If the client machines on your Intranet are running Windows NT or Windows 95, you should have no trouble installing and configuring the built-in TCP/IP support that comes with those operating systems. If, however, you still have Windows for Workgroups 3.11 clients, you will need to install the free TCP/IP 32-bit stack as an add-on. You can either download the latest version from the Microsoft FTP site, or you can install it from the \Clients\Tcp32wfw directory on the Windows NT 4 Server CD-ROM. You can install it on the client machines across the LAN (assuming they are at least running NetBEUI to make an initial connection to the server).
|
A lot of confusion exists about the difference between HOSTS and
LMHOSTS. These terms refer to text files that reside in the \winnt\system32\drivers\etc
subdirectory of Windows NT. I won't be covering these topics in
depth here, so again, please consult Windows NT Server Survival
Guide as a source for detailed information.
Tip |
I highly recommend that you create a desktop icon on your NT machine for the online books on the Microsoft Windows NT CD-ROM. Use Explorer to browse to the \support\books directory, and then drag the file server.hlp to your desktop to create a shortcut. The help files contain loads of technical information about everything from DHCP to User Manager.
|
In addition to the confusion concerning the difference between
HOSTS and LMHOSTS, a separate confusion exists concerning the
difference between WINS and DHCP. To keep the differences straight,
remember that HOSTS goes with DNS, and LMHOSTS goes with WINS.
Notice that I didn't mention DHCP in that sentence; the choice
to run DHCP is independent of your choice to use HOSTS files or
DNS.
HOSTS files can serve as a replacement for DNS if you place identical
files on all the Windows clients in your LAN. HOSTS files map
IP addresses to computer names, one per line. The confusion comes
about because these names are TCP/IP computer names, or host names,
which are quite different from the NetBIOS names you can give
to Windows computers. Microsoft and IBM adopted NetBIOS in the
early days of PCs to provide an efficient network protocol without
forcing users to endure the headaches of TCP/IP configuration
(in those days, TCP/IP required knowledge of UNIX). If you run
your own DNS server on your Intranet, or if you connect to an
Internet Service Provider, you won't need to suffer with the maintenance
headache of the HOSTS files.
DHCP, Dynamic Host Control Protocol, stands alone in this section
as a way to lease valid IP addresses from a large block to the
computers on your LAN as they log into the Windows NT domain.
This capability can be a plus as your LAN grows because you don't
have to worry about coming up with a new address when new computers
are added to the network and, more importantly, you don't have
to be present to help configure the IP address when a conflict
occurs (DHCP only leases available addresses).
LMHOSTS maintains NetBIOS computer name mappings to IP addresses
in the same way that HOSTS maintains DNS computer name mappings.
WINS plays a similar role, but in an automatic fashion, of course,
so you avoid the hassle of updating and copying LMHOSTS files
all over the network. The LM in the name LMHOSTS comes from LAN
Manager, which was an early Microsoft network technology-the grandparent
of Windows NT.
Once you have your LAN up and running, you're going to want to
share files and printers. One of the reasons you'll want to do
this is so that you can write HTML files on your own workstation
before you copy them to the Web server directory on the network
server (assuming, as is most likely the case, that the server
is not your workstation).
In Windows NT 4, you use Explorer to share drives and files on
the computer where they reside. You can still use File Manager
too, if that is what you are used to from NT 3.51. Once you have
shared a drive or directory, such as the WWWRoot
directory where IIS is installed, you can connect to that drive
from another computer on the LAN in a process called mapping a
network drive. The remote drive then becomes a drive letter on
your machine that you can refer to as if it were a local drive.
This process establishes a mapping, or association, between, say,
drive N on your computer and drive D on the server, which is named
banana. But if my computer is on the same LAN, I might
have chosen to map the server drive D to my own drive M, not knowing
that you had called it N on your computer. This difference could
lead to confusion when you and I refer to files on the server
because we each look at the same file and think of it with a different
name.
Windows uses a very simple syntax to refer to network shared drives
in a manner that avoids this potential confusion. This syntax
is called UNC naming, or Universal Naming Convention. The thing
that remains unique in the preceding scenario is the server name
(banana) and the server's drive (D). The only problem is that
the UNC syntax should not conflict with the existing syntax used
for local files and directories. UNC names begin with double backslash
characters to make them unique, and the colon is removed from
the drive letter designation. Continuing the preceding example,
drive M on my computer would have an equivalent UNC name of \\banana\d\.
Drive N on your computer would have the same UNC name, which is
exactly the goal of UNC names. To refer to a file in a subdirectory
on drive N using UNC names, you tack on the pathname and filename
as you would for a local file, for example, \\banana\d\somedir\somefile.txt.
Chapter 7 demonstrates that one reason
this topic is relevant to your Intranet is that UNC names are
required to make IIS virtual directories to other computers.
Each of the tools listed in this section has its place in the
toolbox that no NT Webmaster should be without. Knowing about
these tools is one thing, but being familiar with them is another.
Acquaint yourself with their capabilities at your earliest convenience,
and you will be rewarded day in and day out.
This section introduces you to these tools' purposes and describes
their basic capabilities. Most of these programs have dozens of
options for all kinds of different needs and situations. It is
up to you to try the programs and consult the appropriate documentation
for further information.
ipconfig
If you're running on a network, ipconfig will tell you your own
IP address and other facts about your Network Interface Card (NIC).
ping
You use ping to determine whether another computer running TCP/IP
is reachable from your machine and how long it takes for a packet
to make the round trip back to your computer.
tracert
The tracert tool is the NT console mode application equivalent
to UNIX traceroute. This tool can display the entire route your
IP packets take from your server to the host that you select.
If you have access to the Internet, this tool can be fascinating
to play with when you want to see how fast data can travel halfway
around the world.
netstat
The netstat tool is handy for looking at the status of the LAN.
You can see active connections to all ports and get a statistical
breakdown of all connections over time.
nbtstat
To examine the status of TCP/IP connections that are using NetBIOS
over TCP/IP, use the nbtstat command-line tool.
WinMSD
The handy WinMSD tool is installed in the menu system under Start
| Programs | Administrative Tools | Windows NT Diagnostics. You
can also run this program from the command line (winmsd.exe),
but I use it so often that I created a shortcut icon on the desktop.
WinMSD enables you to browse a lot of valuable system information
without having to resort to separate tools.
Although WinMSD does not let you change any system parameters,
it is a handy one-stop utility for information on OS version,
hardware, memory, drivers, services running, drives, devices,
IRQ/port status, DMA memory, environment, and network configuration.
You can print any of the information displayed or save it to a
file. WinMSD also has a Tools menubar that lets you launch Event
Viewer, Registry Editor, or Disk Administrator. If you ever sit
down at an NT system that you are not familiar with, WinMSD is
the tool to start with. (See Figure 6.3.)
Figure 6.3: Windows NT Diagnostics (winmsd.exe) displays the network settings.
Performance Monitor
Performance Monitor is a great GUI tool that is very easy to use
after you get a little used to it. It gathers good statistics
on IP/TCP/ICMP messages. This tool is your best all-around diagnostic
tool for both the network (if your copy of NT is on a LAN) and
the NT system itself (for example, CPU usage and disk I/O). For
more information about Performance Monitor, consult the Windows
NT Resource Kit.
Note |
To get the most out of Performance Monitor, install the SNMP service along with TCP/IP. With SNMP installed (through the Control Panel Network icon) and enabled (through the Control Panel Services icon), Performance Monitor can track IP packet statistics on your site.
|
The Registry contains important Windows NT data about user preferences
and the hardware and software installed on your computer. Many
of the values kept in the Registry are similar to those that you
would find in the WIN.INI
and SYSTEM.INI files of a
machine running Windows 3.1. The Registry is a hierarchical database
used to maintain configuration information for Windows NT and
the users of the computer.
The Root Keys
The Registry is broken down into four subtrees. (Future versions
of Windows NT might increase this number.) The root key names
at the top of each subtree are prefixed with HKEY
to indicate that they are handles to keys. Windows programmers
speak of a handle as a reference to an operating system
resource. A key is nothing more than a word by which you
can look up an associated value (like a dictionary entry and its
corresponding definition). The next sections cover the four root
keys.
HKEY_LOCAL_MACHINE
The HKEY_LOCAL_MACHINE key
contains information about the local computer system, including
hardware and operating system data such as bus type, memory, device
drivers, and start-up control data. This key is the subtree that
you will be most concerned with.
HKEY_CLASSES_ROOT
The HKEY_CLASSES_ROOT key
contains object linking and embedding (OLE) and file-class association
data.
HKEY_CURRENT_USER
The HKEY_CURRENT_USER key
contains the user profile for the user who is currently logged
on, including environment variables, personal program groups,
desktop settings, network connections, printers, and application
preferences. This key always refers to a user in the subtree of
HKEY_USERS.
HKEY_USERS
The HKEY_USERS key contains
all actively loaded user profiles, including HKEY_CURRENT_USER
and the default profile. Users who are accessing a server remotely
do not have profiles under this key on the server; their profiles
are loaded into the Registry on their own computers.
Editing the Registry
Many of the program configuration changes you make through the
GUI in Windows NT (such as in Control Panel) will be automatically
written into the Registry for you. Whenever possible, allow the
friendly interface of Control Panel and other applications to
write to the Registry on your behalf. Several advanced settings
mentioned in this book, however, can be made only by directly
editing the Registry. To make these changes, use REGEDT32.EXE
(the Registry Editor) as shown in Figure 6.4.
Figure 6.4: Using the Registry Editor to change a DWORD value.
Warning |
If you are not very careful, making changes directly to the Registry can sometimes prevent your computer from working properly. Windows NT displays a standard warning about this problem whenever you invoke the Registry Editor. The warning reads as follows:
Caution: Using Registry Editor incorrectly can cause serious problems, including corruption that may make it necessary to reinstall Windows NT.
|
Most of the Registry values that are changed in this book are
found under HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet.
As you navigate through the Registry with Registry Editor, you
will notice that each entry in the structure is one of three things:
a root key, a subtree, or a value. Value entries don't appear
until you reach the end of a given subtree. Although this structure
might sound complicated, the whole idea is to keep a huge amount
of data organized. You'll see that the Registry serves that purpose
very well, once you get used to it.
I've already discussed the four root keys. Think of subtrees as
branches off of the main trunk, assuming the root keys are the
main trunk. Each value entry has three parts: name, data type,
and the actual value. By default, the Registry recognizes the
following five types of data. The Win32 API includes functions
that programmers can call to add other data types as necessary.
REG_BINARY
The REG_BINARY type is used
for binary data that is uninterpreted by the Registry Editor.
Such data can be interpreted either by the program that writes
the entry or by a system function inside NT that will process
the data at the appropriate time in the execution of the program
that wrote the value. This data type can be used for values that
don't fit any of the other types. Because all data in digital
computers always exists in binary form, usage of the other data
types is only a matter of convenience when the data can be interpreted
by the Registry Editor in a human-readable form.
REG_DWORD
The REG_DWORD data type can
contain 4 bytes of data. The basic unit of memory on Intel and
many other computer architectures is 4 bytes, or 32 bits. This
data type is useful for storing integers.
REG_EXPAND_SZ
The SZ in the REG_EXPAND_SZ
stands for string zero, which means a NULL-terminated array
of characters in C or C++. This data type indicates an expandable
string of text that contains a variable that will be substituted
at runtime. For example, the string %SystemRoot%
appears throughout the Registry. This string will be replaced
at runtime by the actual location of the Windows NT system directory.
REG_MULTI_SZ
The REG_MULTI_SZ data type
is used to hold several string values, each one separated by NULL
bytes.
REG_SZ
The REG_SZ data type is used
to represent a simple array of characters or byte values. As you
traverse the Registry, you will come across numerous examples
of its use for strings of text.
Now that TCP/IP is up and running, the next chapter will bring
the Intranet to life. The Web server will be the vital hub of
your effort.

Contact
reference@developer.com with questions or comments.
Copyright 1998
EarthWeb Inc., All rights reserved.
PLEASE READ THE ACCEPTABLE USAGE STATEMENT.
Copyright 1998 Macmillan Computer Publishing. All rights reserved.